This description relates to managing permissions.
Permissions can be used, for example, to define which features of an application can be accessed and used by which users of the application.
For a large enterprise, the number and variety of features offered by an application can be quite large. Features of an application sometimes support complex flows of work being done by various users in an enterprise. The complex flows may correspond to roles that the users play (e.g., jobs that they have) within the enterprise. In some cases, it is desirable or even critical that users have access only to those features that they need in order to perform their roles.
A given feature can be subject to different kinds of access by users. Some users may have access only to know that the feature exists, for example, by observing a grayed control representing the feature in a user interface, without being able to invoke the feature. Some users may not see the features at all. Some users may have access to invoke and use the feature, for example, by clicking on a button in a user interface.
An enterprise often controls which users of an application can have access (e.g., through a user interface) to which features. Access can be controlled based on the roles of the users, for example, within a hierarchical structure of the enterprise. The hierarchy may be important in that, for example, all of the customer service representatives of an enterprise may have the same permissions, and those permissions may be fewer than the permissions of the manager to whom they report, and so on. We sometimes say that the enterprise, by controlling access, is managing permissions in that permissions are given or withheld for various users to have access to features.
As people are hired, promoted, or depart from an enterprise, as roles change, and as features of an application are changed, permissions need to be updated. For a large enterprise, changes will occur daily or even many times a day. For that reason, typically developers design an application to include a limited set of “hard-wired” functions that enable administrators of the enterprise to manage certain aspects of permissions for the application, rather than requiring the changes to be made by a developer.
A common model for such permissions management functions is a role-permissions model in which specific users are assigned specific roles to each of which a limited number of permissions have been assigned that support the role that the user plays in the enterprise. The role-permissions model implies a matrix in which, for example, the roles appear in successive rows and the assignable features that users in various roles can be granted permission to access appear in respective columns.
Typically, the administrator is given the authority to create, modify, or change profile information about authorized users of the application; to assign or reassign each user to one of the roles for which a given subset of the assignable features have been assigned based on the operating structure of the enterprise; and in some cases to change the features for which all users in a given role have permission. To properly program the permissions management functions of the application, the developer of the application needs to have a working knowledge of each role that users of the enterprise may play, the typical workflow of each role in the enterprise; and the features of the application the permissions to which may need to be restricted based on the workflow and business requirements of the enterprise. Because of the expense and effort of developing administrator functions in an application, only a limited set of such functions can be provided. When the number of roles and the number of features are large, the developer normally must constrain the number of features that can be selectively associated with each role. As a result, the administrator may be constrained to managing a relatively small number of different roles of users of the enterprise and a relatively small number of features for which permissions can be assigned to roles.
For example, for a radiology department of a large medical facility, the developer of an application may be able to include a predefined set of only about 10 to 20 roles and only about 10 to 20 features that can be assigned to each role, yielding a 20 by 20 permission matrix. On one hand, the matrix can be cumbersome to use because a viewer must view 400 potential cells in the matrix to understand which roles have which permissions. On the other hand, the limited numbers of roles and features represented by the 400 cells can severely limit the flexibility of the permissions management task.